1. Field of the Invention
The present invention relates to graphical systems for creating and executing data flow programs, and more particularly to a method and apparatus for providing picture generation and control features in a graphical data flow program.
2. Description of the Related Art
A computer system can be envisioned as having a number of levels of complexity. Referring now to FIG. 1, the lowest level of a computer system may be referred to as the digital logic level. The digital logic level comprises the computer's true hardware, primarily consisting of gates which are integrated together to form various integrated circuits. Other hardware devices include printed circuit boards, the power supply, memory, and the various input/output devices, among others. Gates are digital elements having one or more digital inputs, signals representing 0 or 1 states, and which compute an output based on these inputs according to a simple function. Common examples of gates are AND gates, OR gates, etc. It is also noted that there is yet another level below level 0 which can be referred to as the device level. This level deals with the individual transistors and semiconductor physics necessary to construct the gates comprising the digital logic level.
The next level, referred to as level 1, is referred to as the microprogramming level. The microprogramming level is essentially a hybrid between computer hardware and software. The microprogramming level is typically implemented by software instructions stored in ROM (read only memory), these instructions being referred to as microcode. The microprogramming level can be thought of as including various interpreters comprised of sequences of microcode which carry out instructions available at the machine language level, which is at level 2. For example, when an instruction such as an arithmetic or shift function appears at the machine language level, this instruction is carried out one step at a time by an interpreter at the microprogramming level. Because the architecture of the microprogramming level is defined by hardware, it is a very difficult level in which to program. Timing considerations are frequently very important in programming at this level and thus usually only very skilled, experienced microprogrammers operate at this level.
As mentioned above, the level above the microprogramming level is referred to as the machine language level. The machine language level comprises the 1's and 0's that a program uses to execute instructions and manipulate data. The next level above the machine language level is referred to as the assembly language level. This level includes the instruction set of the computer system, i.e. the various op codes, instruction formats, etc. that cause the computer to execute instructions. In assembly language each instruction produces exactly one machine language instruction. Thus, there is a one to one correspondence between assembly language instructions and machine language instructions. The primary difference is that assembly language uses very symbolic human-readable names and addresses instead of binary ones to allow easier programming. For example, where a machine language instruction might include the sequence "101101," the assembly language equivalent might be "ADD." Therefore, assembly language is typically the lowest level language used by programmers, and assembly language programming requires a skilled and experienced programmer.
The next level includes high level text-based programming languages which are typically used by programmers in writing applications programs. Many different high level programming languages exist, including BASIC, C, FORTRAN, Pascal, COBOL, ADA, APL, etc. Programs written in these high level languages are translated to the machine language level by translators known as compilers. The high level programming languages in this level, as well as the assembly language level, are referred to in this disclosure as text-based programming environments.
Increasingly computers are required to be used and programmed by those who are not highly trained in computer programming techniques. When traditional text-based programming environments are used, the user's programming skills and ability to interact with the computer system often become a limiting factor in the achievement of optimal utilization of the computer system.
There are numerous subtle complexities which a user must master before he can efficiently program a computer system in a text-based environment. For example, text-based programming environments have traditionally used a number of programs to accomplish a given task. Each program in turn often comprises one or more subroutines. Software systems typically coordinate activity between multiple programs, and each program typically coordinates activity between multiple subroutines. However, in a text-based environment, techniques for coordinating multiple programs generally differ from techniques for coordinating multiple subroutines. Furthermore, since programs ordinarily can stand alone while subroutines usually cannot in a text-based environment, techniques for linking programs to a software system generally differ from techniques for linking subroutines to a program. Complexities such as these often make it difficult for a user who is not a specialist in computer programming to efficiently program a computer system in a text-based environment.
The task of programming a computer system to model a process often is further complicated by the fact that a sequence of mathematical formulas, mathematical steps or other procedures customarily used to conceptually model a process often does not closely correspond to the traditional text-based programming techniques used to program a computer system to model such a process. For example, a computer programmer typically develops a conceptual model for a physical system which can be partitioned into functional blocks, each of which corresponds to actual systems or subsystems. Computer systems, however, ordinarily do not actually compute in accordance with such conceptualized functional blocks. Instead, they often utilize calls to various subroutines and the retrieval of data from different memory storage locations to implement a procedure which could be conceptualized by a user in terms of a functional block. In other words, the requirement that a user program in a text-based programming environment places a level of abstraction between the user's conceptualization of the solution and the implementation of a method that accomplishes this solution in a computer program. Thus, a user often must substantially master different skills in order to both conceptually model a system and then to program a computer to model that system. Since a user often is not fully proficient in techniques for programming a computer system in a text-based environment to implement his model, the efficiency with which the computer system can be utilized to perform such modeling often is reduced.
One particular field in which computer systems are employed to model physical systems is the field of instrumentation. An instrument is a device which collects information from an environment and displays this information to a user. Examples of various types of instruments include oscilloscopes, digital multimeters, pressure sensors, etc. Types of information which might be collected by respective instruments include: voltage, resistance, distance, velocity, pressure, frequency of oscillation, humidity or temperature, among others. An instrumentation system ordinarily controls its constituent instruments from which it acquires data which it analyzes, stores and presents to a user of the system. Computer control of instrumentation has become increasingly desirable in view of the increasing complexity and variety of instruments available for use.
In the past, many instrumentation systems comprised individual instruments physically interconnected. Each instrument typically included a physical front panel with its own peculiar combination of indicators, knobs, or switches. A user generally had to understand and manipulate individual controls for each instrument and record readings from an array of indicators. Acquisition and analysis of data in such instrumentation systems was tedious and error prone. An incremental improvement in the manner in which a user interfaced with various instruments was made with the introduction of centralized control panels. In these improved systems, individual instruments were wired to a control panel, and the individual knobs, indicators or switches of each front panel were either preset or were selected to be presented on a common front panel.
A significant advance occurred with the introduction of computers to provide more flexible means for interfacing instruments with a user. In such computerized instrumentation systems the user interacted with a software program executing on the computer system through the video monitor rather than through a manually operated front panel. These earlier improved instrumentation systems provided significant performance efficiencies over earlier systems for linking and controlling test instruments.
However, these improved instrumentation systems had significant drawbacks. For example, due to the wide variety of possible testing situations and environments, and also the wide array of instruments available, it was often necessary for a user to develop a program to control the new instrumentation system desired. As discussed above, computer programs used to control such improved instrumentation systems had to be written in conventional text-based programming languages such as, for example, assembly language, C, FORTRAN, BASIC, or Pascal. Traditional users of instrumentation systems, however, often were not highly trained in programming techniques and, in addition, traditional text-based programming languages were not sufficiently intuitive to allow users to use these languages without training. Therefore, implementation of such systems frequently required the involvement of a programmer to write software for control and analysis of instrumentation data. Thus, development and maintenance of the software elements in these instrumentation systems often proved to be difficult.
U.S. Pat. No. 4,901,221 to Kodosky et al discloses a graphical system and method for modeling a process, i.e. a graphical programming environment which enables a user to easily and intuitively model a process. The graphical programming environment disclosed in Kodosky et al can be considered the highest and most intuitive way in which to interact with a computer. Referring now to FIG. 1A, a graphically based programming environment can be represented at level 5 above text-based high level programming languages such as C, Pascal, etc. The method disclosed in Kodosky et al allows a user to construct a diagram using a block diagram editor such that the diagram created graphically displays a procedure or method for accomplishing a certain result, such as manipulating one or more input variables to produce one or more output variables. As the user constructs the data flow diagram using the block diagram editor, machine language instructions are automatically constructed which characterize an execution procedure which corresponds to the displayed procedure. Therefore, a user can create a text-based computer program solely by using a graphically based programming environment. This graphically based programming environment may be used for creating virtual instrumentation systems and modeling processes as well as for any type of general programming.
The method described in Kodosky et al did not provide any mechanism to allow the user to create pictures or graphics on the front panel other than instrument controls or indicators provided in the application. The user was essentially limited to controls and indicators that were commonly found on instruments, and thus input and output data could only be expressed in this format. However, many times it was desirable to represent data in a different and more intuitive format for ease of understanding.
One problem with providing image or picture generation features in a graphical data flow environment such as that described in Kodosky et al is how to incorporate these features while still maintaining the data flow structure of the environment. The data flow programming model in Kodosky et al is based on nodes that receive data as input, process this data, and then produce output data that is then provided to other nodes. In order to maintain a proper data flow relationship, it is important that nodes not have any side effects, i.e., that they do not change the state of the system in ways not obvious from the data that is produced by the node. It is also important in a data flow environment that nodes be able to generate data that can in turn be passed on to other nodes.
Functional drawing commands typically provided in non-data flow drawing applications would cause problems in a data flow environment. For example, if a node received two points and then immediately drew a line on the screen between these two points, as would occur using a functional library, no data would have been generated by the node representing that the line had been drawn other than the image that appeared on the screen. In addition, the line drawn on the screen would be a change in the state of the system that would not be reflected by any output from the node. This would be contrary to the data flow model provided in Kodosky et al. Therefore, a method and apparatus is desired which provides picture generation and control features in a data flow environment which allow the user to build graphical pictures to represent data, as desired.
Applicant is aware of various drawing applications that allow a user to create pictures on a computer screen. Certain drawing applications receive drawing selections from a user and save these selections as a series of drawing instructions. One problem with many prior art drawing applications is that it is difficult to change a picture after the picture has been completed. For example, if a user creates a picture with a number of shapes, and the user later decides to change certain parameters about each of the shapes, the user is many times required to manually change each shape to affect the desired change in the drawing. Some programs allow the user to change various parameters relating to a picture using a graphical icon, for example, allowing the user to change the color of a picture using a color palette.
Applicant is also aware of a product from Silicon Graphics referred to as Iris Explorer which allows a user to create a flow diagram for performing image processing functions on a received picture. The user can select and arrange various image processing icons in a flow diagram that operate on a received picture to perform various types of image processing on the received picture. This product also apparently allowed the user to create a module or subroutines of a flow diagram wherein only the input and output blocks were displayed.
It would be highly desirable to implement a drawing application as a computer program, and more particularly as a data flow program, to allow a user to more logically and easily construct pictures. In addition, it would be desirable to allow a user to create modular programs which create certain pictures to enable these programs to be used as subroutines in other programs. This would enable the user to more easily construct diagrams using modular subroutines that previously have been created to display certain drawings. It would be highly desirable for a drawing application to include a feature whereby the user could merely change certain parameters using controls on a front panel to affect various desired changes in a drawing. It would also be desirable to allow a user to programmatically design the type and number of controls desired for a respective drawing.